The present invention relates to a distributed computer system and a method of operating a distributed computer system.
The advent of the Internet has meant that it is now much more common for groups of computers to co-operate with one other in some sort of common endeavour. Examples include distributed application programs, different parts of which run on different computers connected to the computer network. The most widely-researched distributed application programs are programs which integrate ‘Web Services’ running on different computers. ‘Web Services’ are one example of components that might be assembled in accordance with a ‘Service Oriented Architecture’. Other known technologies might be used in to build distributed applications—e.g. the Common Object Request Broker Architecture or Enterprise Java Beans.
There is a need for security in such systems. This is especially true of inter-enterprise distributed application programs where computers in one enterprise co-operate with computers in a different enterprise. Whilst an enterprise's system administrator might trust computers administered by that enterprise not to behave maliciously, he is much less likely to trust computers administered by another enterprise to do so.
The conventional technology for securing enterprise networks—i.e. one or more firewall computers through which all traffic entering or leaving the network must pass—is not well suited to inter-enterprise applications. This was recognised in the paper ‘Distributed Firewalls’ by Steven Bellovin which appeared in the November 1999 issue of; login:, pp. 37-39.
It is known to be useful to make system administration policy-based. Policies, as their name suggests, may be applied by a system administrator to a large number of computers in the network administered by that administrator.
In the architecture proposed in the EU research project TrustCOM (see http://www.eu-trustcom.com/) ‘Policy Enforcement Points’ (PEPS) and ‘Policy Decision Points’ are used to provide security functionality to distributed applications formed from a plurality of Web Service components. According to that architecture, the ‘Policy Enforcement Points’ can be co-located with a web-service and/or placed on a node that serves a large number of computers (e.g. a firewall). A message sent between two components of a distributed application may have to pass through a plurality of PEPs. Policy Decision Points are separated from PEPs in the architecture—they can provide access control lists and the like and may be referred to by a PEP when that PEP carries out one or more enforcement actions. The architecture is described in TrustCOM deliverable D19 entitled ‘Basic TrustCOM reference implementation’.
A known way of protecting an enterprise's IT systems from malicious attacks by outsider is simply to isolate the IT systems from the outside world. However, the need to utilise the communication capabilities of the Internet in order to provide a communication channel to customers and suppliers means that this approach is no longer commercially realistic.
When allowing outside access to an IT system, the enterprise must seek ways of preventing malicious code detrimentally impacting the functioning of the enterprise's IT system. One component of defence is to isolate software processes introduced from outside from internally generated software processes. Process isolation can be enforced in a number of ways. Different processes can be run on different computers. However, this disadvantageously increases the power consumed in order to perform a distributed application (though in inter-enterprise distributed applications, some distribution might be inevitable if the enterprises involved keep the computers taking part in the distributed application within their geographical sites).
Where processes are run on the same computer, an interpreter program can allow an external program to access a limited area of memory (e.g. the ‘sandbox’ in which Java applets are allowed to run).
More generally, most operating systems use a CPU's memory management hardware to provide process isolation, using two mechanisms. First, processes are only allowed access to certain pages of physical memory. Second, privilege levels prevent untrusted code from manipulating the system resources that implement processes. However due the high overhead involved with context switching, inter-process communication etc., it is not feasible for every process to be isolated in such a manner.
Thus in almost all commercial systems, code and data are loaded onto same address space and more importantly, shared memory is still used between processes. This means that not only a malicious process could effect another process, but also that unintended failure of one process can effect the other.
Another way of isolating processes from one another is to provide many ‘virtual machines’ on a single computer. This is common on mainframes, and enables many operating system programs to run in parallel on the same machine. Hard disk drive partitioning is another example of virtualization. As the expression ‘virtual machine’ suggests, a virtual machine can emulate a real computer without requiring the separate processor, disk drive, network card and the like that would be required to provide another real computer. Whilst the vast majority of virtual machines will provide virtual processor capacity and memory, not all will provide virtualised versions of all the hardware they are built on—for example not all virtual machines will provide virtual network cards—and hence virtual IP addresses.
Some computers include a hardware Trusted Platform Module and it has been suggested that virtual machines which include a virtual Trusted Platform Module could be provided on such a computer. Examples are the virtual machines disclosed in US Patent application 2006/0256107, US Patent application 2005/0246552, and IBM Research Report RC23879 ‘vTPM: Virtualizing the Trusted Platform Module’.
With virtual machines, each VM partition is given a different virtual address space. Thus, the programs running on one VM cannot in any way access the memory space of another VM. Of course one could go to the extreme of providing a VM at the process level in such a way that each process has a different virtual address space but this would involve an undesirable amount of extra processing.
Also important to note is that virtual machines not just provide isolation in terms of memory access etc. but also in terms of resource usage. For example, a VM could be started with a virtual memory of 512 MB and if a process that is run inside starts behaving anomolously and uses up 400 MB, its effect will be limited to within other processes in the same VM. Other processes in other VMs will not be effected since they use their part of the resource.
Emerging hardware developments are likely to improve hardware support for virtualisation. ‘Virtual machines’ could be mapped onto each of the processors in a multi-core chip, for example. However, as yet, few applications (stand alone or distributed) are written to take advantage of the improved hardware support for virtualisation.
The present inventors have realised that there are many benefits to be obtained by mapping their security architecture onto virtual machines.
According to a first aspect of the present invention, there is provided a computer within a network of computers which interact by passing messages between them in order to perform a distributed application, said computer being arranged in operation to:    i) provide two or more virtual machines, each with its own access control mechanism;    ii) in a first virtual machine, execute one or more local components of the distributed application;    iii) intercept messages for or from local components of said distributed application;    iv) on intercepting a message, execute, in a second virtual machine, a message handling program to perform one or more security actions on each intercepted message.
By keeping and executing message handling programs in a separate virtual machine to a local component whose messages are intercepted by said message handling programs, and having separate access control mechanisms for each virtual machine, one party can be provided with control of message-handling programs whilst another party is provided with control of one or more local distributed application components. This allows those administering the network of computers to control messages sent between the computers in the network (thus enabling the network operator to counter security concerns affecting the network) whilst allowing others to alter local distributed application components (thus providing the benefit of easily updateable distributed applications). This leads to better utilisation of the computer network's resources.
Robustness is provided because the message handling programs are on the same node as the distributed application component they protect and hence are not vulnerable to being accidentally or maliciously circumvented by a change in the topology of the nodes of the distributed computer. Efficiency results since only a single piece of hardware is required for both the message handling program and the distributed application component.
Preferably, the message handling program is configurable by a policy stored in the first virtual machine. This has the advantage that the behaviour of a distributed computer can more easily be updated by a system administrator.
Preferably said computer supports a plurality of local components, each local component being loaded and executed in a local-component-hosting virtual machine dedicated to that local component.
This provides the advantage that local components are isolated from one another since they can only effect the virtual machine they are in. Furthermore, each virtual machine, and hence the local component inside it can be set up with configurable upper limits on resource (e.g. memory, CPU) usage. Yet further, the virtual machines help in preserving the integrity and confidentiality of the data used by the various local components. Yet further still, since virtual machines are isolated stand-alone entities, the administration of local components running within different virtual machines can be handled by different administrators.
Preferably, each local component has an applicable policy stored in the message-handling virtual machine, said message handling program being configured by selecting an applicable policy in dependence on the local component to which said intercepted message relates.
This enables the network administrator to arrange for messages for or from different local components to be handled in different ways.
The inventors have realised that using nodes which include a hardware Trusted Platform Module and providing thereon virtual machines which include a virtual Trusted Platform Module (e.g. the virtual machines disclosed in US Patent application 2005/0246552, and IBM Research Report RC23879 ‘vTPM: Virtualizing the Trusted Platform Module’), further improves the security of the distributed application.
Thus, in particularly advantageous embodiments, said computer node includes tamper-resistant hardware which stores one or more cryptographic keys (especially one or more private keys), and said message-handling virtual machine and/or one or more of said local-component-hosting virtual machines provides its own virtualised version of that tamper-resistant hardware.
In preferred embodiments, one or more of said virtual machines support remote attestation. Thus, for example, a remote user of a local component can check the status of the local component instance's environment.
In preferred embodiments, each virtual machine supports encryption and sealing: the private key and keys generated from it can be used to encrypt data so that any entity outside the virtual machine cannot gain access to the data. Furthermore using sealing these data can be tied to the state of the local component instance that is running in the local-component-hosting virtual machine.